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METHOD AND TERMINAL FOR GENERATING GRAPHICAL USER INTERFACES 



The present invention relates to a method for generation of a user interface. la particular, the 
present invention relates to a method for generation of graphical user interfaces (GUT) on the 
basis of a central configuration arrangement. More particular, the method takes considerations of 
a JAVA programming environment and employs a central configuration arrangement, which is 
coded in a universal markup language such as the extensible markup language. 

Mod^ applications are typically stractured into several application layers, which communicate 
via appropriately designed application layer interfiices. The separation of i^Ucations into 
several spplication layers is clearly i^arent when considering complex £Q>plication projects, in 
which functionality of plication parts has to be handled in a clear and concise way, especially 
when numerous developers are involved in realizing tilie complex application projects. The 
layered structure of complex applications allows for assigning fimctionaUty, which is established 
by one or more application layer fimctions, in a preferably unambiguous manner to certain 
application layers* Moreover when referring to developers involved in realization of complex 
applications independent developer groups of the total niunber of involved developers can be 
assigned to attend to distinct application layers such that competence and responsibility are 
shared and distributed to dedicated single groups, whereby uncertainty and overlapping is 
' avoided, respectively. 

In detail when considering a typical client £q>plication in a client-server environment such an 
application is often separated into a model layer application part, a viewer application part and a 
controller application part which implement model, view and controller pattern. The illustrated 
separation is just exemplary. The following explanation is also applicable with alternative more 
delicate separations. The model layer is dedicated for data handling; which is for example 
requesting, retrieving, communicating and/or storing data. The viewer layer addresses a 
presentation of the handled data; which is for example rendering and displaying of the data. The 
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controller layer arbitrates between the model and the view layer, that is fee controUer layer 
catches events released by users and requests actions of the model layer, which impacts on the 
viewer layer for presentation. In typical cUent applications this enUghtened layer structure design 
is well suited to display common parts of the same data on multiple sci«en masks. All controller 
layer ^plication parts will act of the same model pattern such that all viewer layer appUcation 
parts display the same data. In case of a field within the presentation of the data is modified the 
associated controller layer application part updates flie model pattern such that tiie model layer 
application part notifies connected presentation elements provided by the viewer layer 
application part in order to effect updates presentation of the data. 



It is self-explanatory that the layer design although structured into separate layers does not allow 
for independent implementation. Developers have to take care about consistency b^eai the 
model layer appUcation part and the connection of the viewer and controller layer plication 
parts due to the involvement with each other. The maintaining of consistency counteracts the 
15 initial idea of a separate layered iq>pKcation design. That means, developers which deal with 
model pattern and model layer application part design, have to maintain in paraUel aspects of the 
viewer layer application part and controller layer plication part or to be more general aspects of 
die view and controller patten. 

20 It is an object of the present invention to simplify the design and generation of user interfaces 
which include aspects of the viewer layer application part and controller layer application part. In 
particular, the user interface and to be precise a graphitjal user interface (GUI) is generated 
dynamically at runtime such that model ]ay& ^Ucation part and viewer / controUer layer 
^plication part are clearly separated. 



The object of die present invention is solved by a method for providing a screen mask of a user 
interfece and a tenninal device, which is adapted to perform this method. 

According to an aspect of the invention, a method for establishing a user interface (GUT) is 
30 provided. The user interface (GUI) is operable by a user to operate an application. The 
application is stnictured into separate layers; i.e. a core application layer which is responsible to 
handle data objects and data of the dat^ objects and a viewei/controller application layer, which 



is responsible to display data contained in one or more data objects and to initiate actions 
(events) on the data and the data objects, respectively. The viewer/controller appUcation layer is 
« formed by the user interface (GUI). 

5 Central configuration information is provided, which comprises a component configuration data 
and at least one screen mask configuration data. The component configuration comprises in 
particular component configuration data about all components, which are available to be 
included in screen masks of the user interface. More particularly, the component configuration 
comprises component configuration data about component pattons and the con^nents are user 

10 interfece components also known as widgets. The components are operable as one component 
out of group components, which comimses a component for ou^utting data, a component for 
inputting data and component for botti outputting and irq>utting data. The screen made 
configuration comprises in particular screen mask configuration data about a predetermined 
screen mask of the user interface. The screen mask comprises at least one component, which is a 

15 component out of the group of components comprised by the component configuration. The 
piedetennined screen mask of the user interfece is created on the basis of the central 
configuration infonnation and the at least one component of tiie screen mask is linked to at least 
one data object The linking enables that an action, which is initiated via the at least one 
component effects flie data object and that a modification, which has effected the data object is 

20 noticed by the at least one component such tiiat the conq»onent can react correspondingly. The 
appearance of the user interface is defined by the central configuration information. 
Modifications on the appearance of the user interfece are obtainable by modifications on the 
central configuration information. 

25 According to an embodiment of the invention, the scrfeen mask configuration is retrieved to 
dynamically create the screen mask to be operable with the user interface. As aforementioned, 
tiie screen mask configuration includes, among ottiers, data about at least one component, which 
will be designated in the following as user interfece component. The user interface component 
may be an input component, which is operable by a user for inputting data, information and/or 

30 instructions, onto which an appUcation controUed by tiie user interface reacts by operations, tiie 
user interfece may be an output component, which is dedicated to display infonnation provided 



thereto, or the user interfece component is an input/output component, which is adapted for 
inputting and outputting as afor^entioned. 

The screen mask configuration information is parsed and analyzed to extract type information 
about the at least one user interface component and to extract individual settings (and properties) 
of the at least one usar interface component. The at least one. user interface component is 
obtained on the basis of at least one component pattern, which corresponds to the extracted type 
information and which is provided in conjunction with the widget configuration. The extracted 
individual settings (and properties) are applied onto the at least one user interface component 
obtained by deriving and the at least one user interfece component is included into the 
dynamically created screen ma^ 

The at least one user interfece component of flie screen mask is linked to at least one data object, 
which is preferably provided by a data object container associated to the screen mask. The 
linking allows for adapting the screen mask and the user interface components included in the 
screen mask, respectively, which maybe necessary in case modifications have been performed to 
the linked data object such that an updating (refreshing, repainting,...) of the screen mask is 
required to display valid information hereon. 

According to an embodiment of the invention, the obtaming is initially started by a request for 
the at least one user interface component, which is to be obtained on the basis of at least one 
component pattern, which is to be retrieved from a component pattern repository, which caches 
at least one component pattern. In accordance with the request, the at least one component 
pattern, which corresponds with the extracted type information is identified in the conqwnent 
pattern repository and at least one user interfece conq)onent is derived from the at least one 
identified component pattem. The at least one derived user interfece conq)onent is finally passed 
back in accordance with die request. 

According to an embodiment of the invention, the component pattem repository is initialized 
previously. The initiaUzation is based on a component configuration, which comprises 
component configuration information about at least one component pattem. The component 
configuration is parsed and on the basis of the parsing results, the at least one component pattem 
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dp 

corresponding to the component configuration information is created. The at least one created 
component pattern is stored / cached in the component pattern repository. 

Accordmg to an embodiment of the invention, the component pattern repository contains 
5 statically the at least one component pattern, i.e. statically during runtime of the user interface 
and the ^plication that is controlled by the user interface, respectively. 

According to an embodiment of the invention, the obtaining of the at least one user interface 
component comprises a request for the at least one user interfiice component, which is to be 

10 obtained on the basis of at least one component pattem. A component configuration is provided, 
which comprises component configuration information about at least one component pattem. 
Component configuration information about the at least one component pattem, which 
corresponds to the extracted type information is identifies and parsed. On the basis of the parsing 
results, the at least one component pattem is created and the at least one user interface 

15 conq>onent is derived from the at least one component pattem. Finally, the at least one user 
inter&ce component is passed back. 

According to an embodiment of the invention, the deriving of tiie at least one user interface 
component comprises furttier a cloning procedure, which allows to obtain the at least one user 
20 interface component in a heredity process fix)m the at least one component pattern. 

According to an embodiment of the invention, the component configuration comprises default 
component configuration information about at least one component pattem. That means that the 
user interface components, which are obtained from the least one component pattem, each have 
25 default settings (and properties), which are substantially valid for each screen mask, into which 
the user interface components are included. 

According to an embodiment of the invention, the screen mask configuration comprises screen 
mask configuration information about at least one user interface component. The screen mask 
30 configuration infonmation is required to ads^ted user interface components, which are obtained 
from component patterns by deriving, to individual requirements, which are presi^posed by tiie 
screen mask to be created. 
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According to an embodiment of the invention, the screen mask configuration is an XML-encoded 
«. screen mask configuration, which is based on a screen mask document type description (DTD). 

5 According to an embodiment of the invention, the widget configuration is an XML-encoded 
widget configuration, which is based on a widget document type description (DTD), 

According to an aspect of the invention, a software tool for establishing a user interface (GUI) is 
provided. The software tool comprises program portions for carrying out the operations of the 
10 aforementioned methods when the software tool is implemented in a computer program and/or 
executed. 

According to an aspect of the invention, there is provided a compute: program product for 
estabUshuxg a user interface (GUI). The computer program comprises program code portions 
15 directly loadable into a local memory of a microprocessor-based component, processing device, a 
terminal device, a communication terminal device, a serving device or a network device for 
canying out the operations of the aforementioned methods when the program is executed 
thereon. 

20 According to an aspect of the invention, a computer program product for estabUshing a user 
interface (GUT) is provided which comprises program code portions stored on a computer 
readable medium for carrying out the aforementioned methods when the program product is 
executed on a microprocessor-based component, processing device, a tebninal device, a 
communication terminal device a serving device or a network device. 



25 



30 



. Accprdmg .to an aspect of the invention a computer data signal is provided which is embodied in 
a carrier wave and represents instructions which when executed by a processor cause the 
operations of anyone of the aforementioned methods to be carried out. Thereby Internet 
applications of the invention are covered. 

According to an aspect of the invention, a terminal device is provided, which processes a cUent 
appUcation with a user interfece for displaying content of at least one data object to a user. The 
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tenninal device forthar includes a screen mask creating conq)onent for d>nainical creation of a 
screen mask of the user interface (GUI). The screen mask creating component preferably embeds 
a retrieval component, which allows for retrieval of a screen mask configuration. The screen 
mask configuration comprises, among others, screen mask configuration information about at 

5 least one user interface component, which is parsed by an adequate parser (parsing component) 
such that type infomiation about the at least one user interface component and individual settings 
(and properties) of the at least one user interface component are available from the screen mask 
configuration. The at least one user interface component is obtained by a widget creating 
component on the basis of at least one component pattern, which corresponds to tiie type 

10 information and die individual settings (and properties) are ^plied additionally onto the at least 
one derived user interface component. 

The at least one user interface component is preferably logically linked together by a linking / 
binding component with at least one data object which includes data content relating to the at 
15 least one user interface component The linking ensures that in case of modifications occm, 
which affects the at least one linked data object, the displaying of the user interface component 
included in the screen mask is updated. 

According to an embodiment of the inv^tiont, a component pattern repository is provided, which 
20 caches at least one component pattern and firom which at least one user interface component can 
be requested. An identification component allows for identification of at least one componmt 
pattern, which corresponds to the extracted type information. The widget creating component is 
further adapted to derive at least one user interface component from the at least one identified 
component pattern. 

25 

According to an embodiment of the invention, the terminal device comprises further components 
for initializing the component pattern' repository. A retrieval component is adapted to provide a 
component configuration, which comprises, among others, component configuration information 
about at least one component pattern, which is analyzed by a parser (parsing component). In 
30 conjunction with the parsing results, the widget creating component is adapted to create the at 
least one component pattern and to store / cache the at least one created component pattern in the 
component pattern repository. 
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According to an embodiment of the invention, the terminal device further comprises a retrieval 
component, which aUows for retrieval of a component configuration. The component 
configuration includes, amoQg others, component configuration information about at least one 
conq>onent pattejn. which is analyzed by a component of identifying the component 
configuration information about the at least one component pattern, which corresponds to the 
extracted type information. The identification component configuration infonnation is parsed by 
a parser (parsing component) and on basis of the parsing results, at least one component pattern 
is created and at least one user interface component is derived therefiom by the widget creating 
component adapted thereto. 

The accompanying drawings are included to provide a fiirther understanding of flie invention and 
are incorporated in and constitute a part of this specification. Tlie drawings illustrate 
embodiments of the present invention and together with the description serve to explain the 
principles of the invention. In flie drawings. 

Fig. la illustrates an initial operational sequence for initializing a widget cache according to 

an embodiment of tiie invention; 
Fig. lb illustrates an operational sequence for creating a screen mask according to an 

embodiment of flie invention; 
Fig. Ic depicts a component model, which illustrates components performing the operational 

sequences illustrated in Fig. la and Fig. lb .according to an embodiment of the 

invention; 

Fig. 2 depicts a component model, which Ulustrates the XGF framework in an example 

cUent-server environment according to an embodiment of the invention; 
Fi&Ja ...shows a clear t^t coding of an example document type description, which includes 

type definitions of several widgets according to an embodiment of the invention; 
Hg. 3b shows a clear text coding of an example widget configuration, which includes 

common property settings on the basis of the document type description shown in Fig. 

3a according to an embodiment of the invention; 
Fig. 4a shows a clear text coding of an example document type description, which includes 

type definitions of screen masses according to an embodiment of the invention; 



Fig. 4b shows a clear text coding of an example screen mask configuration on the basis of the 
document type description shown in Fig. 4a according to an embodiment of the 
invention; * 

Fig. 4c depicts an example screen mask, which corresponds to the example screen mask 

definition shown in Fig. 4b according to an embodiment of the invention; 
Fig. 5a illiistrates a schematic diagram which illustrates the binding of data objects and 

widgets according to an embodiment of the invention; and 
Fig. 5b illustrates a schematic diagram that depicts the logical linkage of componeiits 

intaractiag with each othia: on handling a data object change notification according to 

an embodiment of the invention. 

Reference will be made in detail to the embodiments of the invention examples of which are 
illustrated in the accompanying drawings. Wherever possible the same reference numbers are 
used in the drawings and the desc^ption to refer to the same or like parts. 

The following description for enlightraiing the inventive concept of tiie present invention will be 
given in view of a user inter&ce, which is presented to a user of a client ^pUcation, which 
prefoably is operable with a data management application such as a database management 
system (DBMS). The data management application may preferably be networked application and 
a server plication, respectively, such as known in ^ical client-server environments, in ^ch 
one or more client temiinals are operable with the client application and a central server device is 
operable with the networked data management application. The user interface in question is 
preferably a graphical user interface (GUT), which includes graphical elements comprising screen 
masks and graphical components included in the screen masks. A screen mask shall be 
understood as a presentation area, upon which a plurality of graphical components is arranged. 
For simplicity tiie term screen mask will be abbreviated in the following description as screen. 
Correspondingly, compound words containing tiie temi screen mask wiU analogously simpUfied 
by including the term screen. The components are input/output elements of tiie gr^hical user 
interface (GUI), which on one side aUow for displaying data (corresponding to viewer layer) and 
which on tiie other side allow for inputtmg requests (corresponding to controller layer). The 
graphical components are also commonly designated as widgets. 
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The description will first introduce into creating and providing of component entities and in 
particular component patterns and component instances, respectively. The component patterns 
" are made available statically during runtime of the client application. The statically provided 
component patterns serve as basis of patterns to retrieve dynamicaUy components and component 
5 instances, respectively, which are to be included into dynamically created screens. In particular, 
the components to be included into a dynamicaUy created screen are obtained by a deriving 
process or cloning process from the statically provided component patterns, hi the following the 
above described components patterns and component (and component entities, respectively) will 
be designated as widget patterns and widget (and widget entities, respectively), without limiting 
10 the invention thereto. 



Fig. la illustrates an initial operational sequence for creating widget patterns and for mitializmg a 
widget repository mcludmg the created widget patterns according to an embodiment of the 
invention. . 

15 

In an operation SlOO, a creating of widget patterns and an initializing of an adequate widget 
repository with the created widget patterns is started. The widget repository or widget pattern 
repository is a static collection of widget patterns. The designation "static" shall be understood as 
static during runtime of the ^Hcation and wherein the widget patterns stored in the widget 
20 repository shall be also understood as basis of patterns, on the basis of which widgets of a 
gr^hical user interface (GUI) are derived and cloned, respectively. Herein, the widget repository 
area will also be referred as widget storage and widget cache, respectively. 

In an operation SI 10, a widget configuration is retrieved. The widget configuration comprises 
25 information about properties and settings q>plicable to widgets defined therein, hi particular the 

widget configuration is provided as a widget configuration file stored , centrally. The . widget 

configuration primarily relates to common (global) properties and settings of defeult widgets, 
whidi at least allow for establishing a common look and feel of the graphical user interfece 
(GUI) composed thereof. The common look and feel of graphical user interface (GUI) and 
30 elements/conqjonents therefor is one of the essential featiu-es, which have to be taken into 
consideration to enable a convincing, user-fiiendly and intuitive operativness of the graphical 



11 

user interface (GUI), and thus of the client application that communicates with the user via the 
graphical user interface (GUI). 

More particular, in accordance with one preferable embodiment of the invention the widget 
5. configuration is based on the extensible markup language (XML), The extensible markup 
language (XML) is a universal language construct which allows for coding arbitrary information, 
the meaning of which is defined by language tags and markups, respectively, which are defined 
and described in a corresponding docummt type description O^TD). A detailed description of the 
application of XML-coded widget configuration on the basis of a widget document type 
10 description (DTD) will be referred to in Fig. 3a and Fig. 3b. 

In an operation S120, the widget configuration is parsed. The parsing and interpreting of the 
widget configuration, which is preferably XML-coded, is performed on the basis of pre-defined 
parsing agreements, in particular on the basis of a corresponding document type description 

15 (DTD). The pre-defined parsing agreements, i.e. the document type description (DTD), ensure 
that the parsing is operable and parsing results are unambiguous. In an opraation SI 30, a widget 
pattern is created in accordance widi the parsing results. And in an operation S140, the created 
widget pattern is stored in the dedicated widget repository such that the created widget pattern is 
retrievable for further employment such as in particular for including widgets into a dynamically 

20 created screen, which is described in following Fig. lb. 

The operations S120 to S140 have been described with respect to parsing of the widget 
configuration, creating of a widget pattern and storing the created widget pattem. The widget 
configuration may relate one or more different widgets, which lead to one or more widget 
25 patterns. Correspondingly, either the operations S120 to S140 are repeated subsequently for each 
mdividual widget / widget pattem as illustrated in Fig. la or each operation of the operations 
S120 to S140 performs immediately for each widget / widget pattem to be created and stored 
such tiiiat a repetition of the operations S120 to S140 is not necessary. 

30 In an operation SI 50, the creation of widget patterns defined in the widget configuration is 
finished and the created widget patterns are stored in the widget repository for further 
employment 
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Fig. lb iUustrates an operational sequence for dynamical oreating a screen on the basis of the 
widget patterns provided by the widget repository according to an embodiment of the invention. 

In an operation S200, a dynamical creating of a sraeen on flie basis of a previously created and 
initialized widget repository is started. The widget repository is a static coUection of widget 
patterns. The designation static shall be understood as static during runtime of the application 
and the widget patterns stored in the widget repository shall be also understood as widget 
patterns, by the means of which widgets (widget instances) are derived and cloned, respectively, 
to be included into a dynamicaUy created screen of a gr^hical user interface (GUI). 

In an operation S210. a screen configuration is retrieved. The screen configuration comprises 
information about widgets to be inchided into the screen and properties and settings appUcable 
with the distinct screen and the components thereof respectively. Jn particular the screen 
configuration is provided as a screen configuration file stored centrally. The screen configuration 
relates to properties and settings of the screen in question, screai related properties and settings 
of widgets (widget instances), exceptional properties and settings of widgets (widget instances) 
included in the screen, arrangement of the widgets on the screen. 

More particular, in accordance with one preferable embodiment of the invention the screen 
configuration is based on the extensible markup language (XML) in conjunction with a 
corresponding appropriate screen document type description (DTD). A detailed description of the 
appUcation of XML-coded screen configuration on the basis of the screen document type 
description (DTD) will be referred to in Fig. 4a and Fig. 4b. 

..lh„w operation S220, the screen configuration is parsed. The parsing and interpreting of the 
screen configuration, which is preferably XMI^coded, is performed on the basis of pre-defined 
parsing agreements, in particular on the basis of a corresponding document type description 
(DTD). The pre-defined parsing agreements, i.e. the document type description (DTD) ensures 
fliat the parsing is operable and parsing results are unambiguous. 
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la an operation S230, the screen is dynamically created in accoidance with the parsing and 
parsing results, respectively. 

In a sub-operation S231, a widget to be included into the sareen is preferably requested from the 
widget repository- The widget repository caches widget patterns. The request instructs to deliver 
a widget and a widget instance of a certain predetermined widget type, respectively. The type 
mformation on the basis of which the widget is requested is received from the parsing operation 
and can be concluded from tiie screen configuration, which defines all widgets to be included'in 
the screen in question. 

In detail the request for a widget and widget instance may require an identifymg of that widget 
pattern, which corresponds to the widget currently in question. A corresponding widget pattern 
maybe obtained from the widget repository, which provides statically a total collection of widget 
pattern, which may be eiiq>loyed in screens of the graphical user interface (GUI). On basis of the 
idCTtified widg^ pattern a widget and a widget instance is created, respectively. That means, the 
widget is doived or cloned fiom the widget pattern such that the default properties and settings^ 
which have heea applied to the widget pattern during creation thereoi^ get valid for the obtained, 
widget and widget instance, respectively. This is to ensure the look and feel defined in view of 
the ovCTall substantially identical widget lefvesentation of the gisqphical user interface. 

In a sub-operation S232, mdividual properties and settings, which are instructed and provided by 
the screen configuration with respect to the widget currently in question, are applied to the 
requested widget. The individual properties and settings may comprise screen related prop^es 
and settings, which have to be applied to the widgets of the screen to enable a suitable operation 
in view of tiie screen function. The individual properties and settings may also comprise 
exceptional properties and settings, which are applied to depart from the default settings, which 
result fiom the deriving and cloning process for creating the widget in question from the 
corre^onding identified widget pattern, respectively. More commonly, the widget in question 
obtained fiom the widget pattern is adapted to screen related necessitates and requirements. 

The op^ations S220 to S232 have been described with respect to parsing of ttie screen 
configuration and creating of the screen by requesting a widget fiom the widget repository and 
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applying individual properties and settings onto the widget obtained by the request. The scr^ 
configuration may define one or more different widgets to be included in the screen in question. 
Correspondingly, either the operations S220 to S232 (or tiie operations S230 to S232) are 
repeated subsequently for each individual widget as Ulustrated in Fig. lb or each operation of the 
operations S220 to S232 performs immediately for each widget to be created and included such 
that a repetition of the operations S220 to S232 is not necessary. 

In an operation S240, the dynamical creating of the screen on the basis of a previously created 
and initialized widget repository is finished. 

Fig. Ic depicts a first component model, which illustrates components, which aUow for 
performing the operational sequences illustrated in Fig. la and Fig. lb according to an 
embodiment of the invention. A first part of the illustrated component model relates to the 
method of creating widget patterns and initialization of the widget repository with the created 
widget patterns according to an embodiment of the mvention. A second part of the illustrated 
component model relates to tiie method of dynamical creating a screen of a graphical user 
interface (GUI) on the basis of previously created, widget patterns stored in the widget rq>ositoiy. 

The first part is exemplary composed of a widget configuration 310. which is provided for 
20 defimng defeult widget patterns. Preferably, the widget configuration 310 is stored in an 
adequ^e storage component (not shown), which allows for storing and retrieving the viddget 
configuration 310. M the operation SllO. tire widget configuration is retrieved or read fiom tiie 
storage component and supplied to a parsmg component, which is herem embodied as an XML 
parsing component arid an XML parser 250, respectively. The XML parser 250 is responsible for 
parsing tiie widget configuration 310 in tiie operation S120 and supplies parsing results to a 
. Widgftt ere^tiog component and a widget factory 230. respectively, for creating in -flie operation 
S130 one or more widget patterns on tiie basis of tiie parsmg results. Finally m tiie operation 
S140, flie created widget patterns are passed on to a widget cache 210, which caches / stores flie 
created widget patterns such as exemplary widget patterns 41 1 and 412. 
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The second part is exemplary composed of a screen configuration 320, which is provided for 
defining a certain predetermined screen. Preferably, tiie screen configuration 320 is stored in an 
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adequate storage component (not shown), which allows for storing and retrieving tiie screen 
configuration 320. In the operation S210, the screen configuration is retrieved or read firom the 
storage component and supplied to a parsing component, which is herein embodies as an XML 
parsing component and an XML parser 250, respectively. The XML parser 250 is responsible for 
parsing the screen configuration 320 in the operation S220 and supplies parsmg results to a 
screen cieating component and a screen fectory 240, respectively, for creating in the operation 
S230 the screen on the basis of the parsing results. The creating of the screen by tihie screen 
factory 240 includes in the operation S231 a requesting of one or more widgets. One or noiore 
requests for widgets are addressed to the widget cache 210 and the one or more requests are 
answered by responses comprising coiresponding widgets and widget mstances, respectively, 
which are obtained for the widget patterns serving as a basis of patterns, which are cached in the 
widget cache 210. The cloning of a widget pattOTi to obtain a widget and widget instance, 
respectively, is preferably performed by the widget factory 230 but may be also carried out by the 
screen factory 240. The designation "cloning" should be understood as a creating of a widget on 
the basis of a correspondmg widget pattern by passing on properties and settings defined in 
conjunction with the widget pattern to the widget The passing on may be understood as heredity 
of properties and settings, which is known in the field of object-oriented modeling and 
programming. Finally, tiie created screen may be provided to the graphical user inter&ce (GUI; 
not shown) for being displayed and/or may be passed on to a screen cache (not shown) for 
caching (storing) ttie created screen for later use. 

Fig. 2 depicts a second component model, which illustrates the XML-based graphical user 
interface factory (XGF) framework in an example client-server environment according to an 
embodunent of the invention. The Fig, 2 illustrates details on an example XGF core architecture 
» structured in components, which allow for performing the aforementioned method for creating 
widget patterns and for initialization of the widget repository and the aforementioned method for 
dynamically creating a screen according to embodiments of the invention. This XGF framework 
is preferably embedded as an application part or application layer into the client application, to 
which the graphical user interface (GUI) in question belongs. 

In detail, the client application 100 comprises a client code component / section 1 10 and an XGF 
framework component / section 200. The client application 100 may be carried out on one or 
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more suitable processing devices (not shown) such as microprocessor-based terminals (PC, 
network clients etc.). A file server 300 serves for providing the widget configuration 310, the 
screen configuration 320, the widget document type description 330 and the screen document 
type description 340. The file server 300 and the processing devices carrying out the client 
appUcation 100 communicate with each other via a data communication network such as a local 
area network or any other suitable network. Alternatively, the configurations 310 and 330 as well 
as the document type descriptions 330 and 340 may be included in the XGF framework 
component 200. In a client-server environment, in which client appUcations access data which is 
managed centrally on a server such as a database management server, it is advantageous to 
centralize also configuration information, which is to be supplied to the cUait appUcations since 
the network and server firamework is ahneady avaUable. In case of changes on &e configuration 
infoxmation the changes have automatically effect on each client j^lication. 

The XGF firamewoik component 200 comprises fiirther a file loader interfece 260, which is 
responsible for retrieving the configurations 310 and 330 as well as the document type 
descriptions 330 and 340 &om the file server 300. An interconnected file cache 270 may be 
employed to cache lbs configurations (310, 320) and descriptions (330, 340) to increase the 
processing speed by obviating the necessity of retrieval of the configurations and descriptions 
fix>m the file server 300. The file cache 270 may be implemented as a local mass storage 
component (e.g. hard disk) and a timestamp identification of the configurations and the 
descriptions may be used to identify modified configurations and/or descriptions such that a well- 
dedicated re-retrieval of the changed configurations and/or descriptions is operable. 

The file loader interfece 260 supplies the configurations 310 and 330 as well as the document 
type descriptions 330 and 340 to the widget fiictory 230 and the screen fectory 240, respectively. 
The widget fkctory 230 and the screen factory 240 ar« adapted to carry out -the corresponding 
aforementioned methods according to embodiments of &e invention. 

In detail, the widget factory 230 is adapted to carry out the operational sequence for creating 
widget patterns and for initialization of the widget repository caching the created widget patterns 
according to an embodiment of the invention. The widget fectory 230 may be a code section 
comprising instructions which when carried out on a processing device (e.g. microprocessor 
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based terminal) performs the aforementioned method. In particular, the widget factory 230 may 
be part of a parser 250, which is adapted to parse and interpret XML-coded configurations. The 
widget factory 230 is adapted to parse the widget configuration 310 and stores / caches the 
created widget patterns in the widget cache 210 associated with the widget factory 230. The 
created widget patterns act as patterns having default properties and settings pre-determined in 
the widget configuration 310 for the graphical user interface (GUI), which serves user as the 
interface of the client application 100, The default properties and settings relate primarily to a 
common look and feel of the graphical user interface (GUI) representation. The widget patterns 
stored in tiie widget cache 210 are statically available during runtime of the client application 
100. 

In detail, the screen factory 240 is adapted to carry out the operational sequence for dynamical 
creating a screen on the basis of widget patterns provided by the widget repository according to 
an embodiment of the invration. The screen factory 240 may be a code section comprising 
instmctions which when carried out on a processing device (e.g. microprocessor based terminal) 
performs the aforementioned method. In particular, the screen factory 240 may be part of a parser 
250, which is adapted to parse and interpret XML*coded configurations. The screen factory 240 
is Bdapted to parse the screen configuration 320 and to dynamically create a screen for being 
presented to the user within the context of the graphical user interface (GUI) of the client 
application 100. A screra cache 220 allows for storing / caching created screens, which enables a 
seeding up of screen representation in case a previous created screen is to be displayed again. 

The deriving of widgets firom widget patterns, which are cached in the widget cache (widget 
repository) 210 may be performed by the widget factory 230 or by the screen factory 240. 
Preferably, the widget factory 230 is responsible for derivmg (cloning) a widget firom a 
corresponding widget pattern. 

Moreover, the screen factor 240 is furttxer adapted to link data objects and dynamically created 
screens with each other. In particular, the screen factor 240 is further adapted to link data objects 
and widgets included in the dynamically created screens with each other. A detailed description 
of the linking and the purposes thereof is described below with reference to Fig. 5a and Fig. 5b. 
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^ The following Fig. 3a to Fig. 4b depict an example widget document type description (DTD), an 
example XML-based widget configuration, an example screen document ^e description (DTD), 
an example XML-based screen configuration. The presented example document type 
descriptions and example configuration files comprises elements, which refer to JAVA 

5 programming language. 

It is to be understood that the references to the JAVA programming language as well as flie 
concrete XML-coding are not limiting to the scope of the present invention. The adaptation to 
other programming languages and GUI libraries is possible. Moreover, the depicted XML-coding 
10 scheme is not limited to the depicted XML version and the character encoding QSO 8859-1), 
respectively. A detailed description of the aspects of the extensible markup language (XML) and 
in particular of the notation of XML document type descriptions may be found in "Extensible 
Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation 6 October 2000, 
published by the World Wide Web Consortium. 

15 

With reject to the following aforem^tioned examples, a document type description comprises 
sets of declarations that provide a grammar for a class of documents that refer to that document 
^e description. Each set of declaration may be an element type declaration having one or more 
attribute type declarations associated to the element type declaration. In particular, an element 
20 type declaration has one or more atbibute type declarations arranged hierarchically subordinated. 
The XML-based configurations are drawn up and parsed on the basis of these grammatical 
declarations provided by the document type description. . 

Fig. 3a shows a clear text coding of an example widget document type description, which 
25 includes type declarations of several widgets according to an embodiment of the invention. The 

presented .widget document type definition (DTD) specifies element type declarations . and one or 

more attributes assigned to a corresponding element ^e declaration. Each element ^e 
declaration in conjunction witii its assigned attribute type declarations refers to a widget and its 
properties for an individual widget configuration. Moreover, ttie ^e declaration specifies the 
30 hierarchy for the widget configuration. 
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In line 2 an element "widgetdefinition" is defined and the element type declaration specifies that 
the element "widgetdefinition" may comprise one or more fiirther specified elements (cf. line 2: 
"panel", "button", "Ustbox"... "tabpane") to be airanged hierarchically subordinated. Moreover, 
the element type "widgetdefinition" has fiirther assigned an attribute type declaration which 
includes an attribute "laf ' (abbr.: look and feel), which is specified to be obUgatory and to have 
assigned one of the possible attribute values "metal", "motif', "windows", "mac". 

hi lines 6, 11, 16, 21, 26, 35 and 46 are denoted the element type declarations of the elements 
which are allowed for being included in the element "widgetdefinition". 

For example, the element "button" is defined in line 16 and relates to the element type 
declaration of the widget "button". The type declaration of the element "button" specifies that 
elements "bevelboider" and "font" may be included in the definition of the element "button". The 
element type declarations of the elements "bevelborder" and "font" foUows &om the lines 30 to 
34 and lines 39 to 45, respectively. Further, an attribute type declaration comprising two 
attributes of the element "button" is specified in lines 17 to 20. The attributes comprise an 
attribute "class" (cf. Ime 23) and an attribute "name" (cf line 24). The attribute "class" is defined 
as obUgatory whereas &e attribute "name" is defined as optional. Botti attributes are defined to 
accept character-encoded data contraot (CDATA). 

The element type declaration of the element "font" relates to a font appearance definition and is 
denoted in lines 39 to 45. The element "font" is a subordinated element to be included in element 
definitions, which relate to widget elements such as the element "button" explained above. The 
element "font" comprises an attribute type declaration, which includes four attributes. The 
attributes "name" (ct line 41). "size" (cf. line 42) and "style" (cf. line 43) are specified as 
ObUgatory and ttie attributes "name" and "size" are defined to contain character-encoded data 
content, whereas the attribute "style" is defined to have one value out of the group "plain", "bold" 
and "itaUc". The attribute "class" is defined to contain constant data and has assigned fixly a 
constant JAVA class definition. 

The element type declaration of the element "bevelborder" relates to a border styUng and is 
denoted in Unes 30 to 34. The element "bevelborder" is a subordinated element to be included in 
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element definitions, which relate to widget elements such as the element "button" explained 
above. The element "bevelborder" comprises an attribute type declaration which includes two 
attributes: the attribute "class" (of. 32). which is defined to contain constant data and has assigned 
fixly a constant JAVA class definition, and the attribute "boider" (cf. Une 33), which is defined 
as obligatory and to have one value out of the group "lowered" and "raised". 

The given above explanation of the elements "button", "font" and "bevelborder" introduces 
exemplary in the denotation of the widget document type definition. On basis of Ae 
aforementioned description the fiirther element type declarations can be understood. Moreover, 
the description will be more sqiparent when referring^to Fig. 3b. 

Fig. 3b shows a clear text coding of an example widget configuration, which includes common 
widget property settings and which is coded on the basis of the document type description 
described with respect to Fig. 3a according to an embodhnent of the invention. The widget 
configuration comprises only a selection of individual widget definitions, on the basis of which 
widget patterns are derived such as described with reference to Fig. la. to accordance with the 
widget DTD (cf. Fig. 3a and description) the widget configuration begins with the 
widgetdefinition element in line 3. The individual widget definitions of individual widget 
patterns are arranged hierarchically subordinated to the element "widgetdefinition". such that 
Imes 4 to 6 include an individual widget definition "button", lines 7 to 9 include a an individual 
widget definition "panel", lines 10 to 13 include an individual widget definition "Ustbox", lines 
14 to 17 include an individual widget definition "texibox" and lines 20 to 23 inchide an 
individual widget definition "label". 

to accordance with the fimction of the widget configuration, each mdividual widget definition 
includes a-set of default. attribute definitions. For example, the definition "textbox^* mcludes an 
attribute "class", which is assigned in line 14 to a component class of the JAVA programming 
language. Further, the definition "textbox" specifies in line 15 an element "font" and property 
attributes thereof, which are arranged hierarchically subordinated to the definition "textbox"; i.e. 
the attribute "name" of the font ("Anal") to be used, the attribute "size" of the font ("10" pt) and 
the attribute "style" of the font ("plain"), to line 16 the definition "textbox" includes also an 
element "bevelborder" and a propetty attribute thereof which are airanged hieraichicaUy 
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subordinated to the definition "textbox"; i.e. the attribute "border" set to "lowered". The 
assignments of the attributes to certain predetermined values form the default configuration of 
the widget pattern "textbox", on the basis of which one or more widgets to be displayed in 
conjunction with the graphical user interface (GUI) are requested. Pue to this default 
configuration of the definition "textbox", "textbox" widgets, which may be included into a 
created screen, show all the same appearance; i.e. have the same look and feel. 

Analogously, the description given above wift reference to the widget definition "textbox" 
applies also in a similar way to the fiirflier widget definitions. As an example in short, ttie widget 
definition "label" comprises assignments of an attribute "class", an element "font", which 
comprises the aforementioned font attributes, and an elanent "bevelborder" which comprises die 
aforemoxtioned border attribute. 

Conclusively, it shall be understood that the widget document type definition pTD) specifies the 
15 elements, attributes, types of the attributes, the hierarchical structure of the elements and 
attributes and the totally supported and available grammatical elements of the widget 
configuration, which is coded as an XML file and which is based on the grammatical elements 
specified in the widget document type definition (TDTD). In accordance with an embodiment of 
the invention, the definitions specified in the widget configuration are defiiult definitions; this is 
20 tiie definitions may not include all definitions specified as being obUgatory and defeult 
definitions maybe superset by individual definitions. The default assigmnents primarily concerns 
properties such as background / foreground color, fonts, optical appearance, ... and more 
specifically a mapping of the logical widget elements type to a concrete implementation such as 
the imping to the JAVA implementation classes described above. 

25 

The widget document type definition (DTD) is maintained and in the responsibiUty of Hhs 
developers of XGF core implementation since changes or modifications on tiie widget document 
type defimtion (DTD) affects the parsing operation and tiierefore tiie corresponding paismg 
fimction embodied in Fig. 2 as widget fectory. New components as new widgets of tiie employed 
30 graphical user interface (GUT) or new properties (attributes) of widgets entaU a modification of 
tiie widget document type description (DTD). The maintenance of tiie widget configuration is in 
the responsibility of both core developers and GUI developras. 
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Common explanations with respect to document type descriptions and XMI^encoded 
configurations being based on the docmnent type descriptions given with reference to Fig. 3a and 
Fig. 3b apply analogously to tiie following description referring to Fig. 4a and Fig. 4b. 

Fig. 4a shows a clear text coding of an example screen document type description, which 
inchides type declarations with reference to screens according to an embodiment of tiie 
invention. 

The presented screen document type definition (DTD) specifies additional element type 
declarations and one or more athibutes assigned to a corresponding element type declaration and 
amplifies element type declarations, v/bich are introduced with reference to tiie widget document 
type description shown in Fig. 3a, by additional attribute type declarations. 

In Ime 2 an element "screen" is defined and tiie element type declaration specifies that the 
element "screen" comprises a element "panel" (cf. line 2: "panel") to be arranged hierarchically 
subordinated. The element type "screen" has fiirther assigned an attribute type declaration which 
includes an athibute "name" (cf. line 4), which is specified to contain character-encoded data 
• content and to be compulsory, and an attribute "class" (cf. line 5), which is specified to contain 
character-encoded data cont^t and to be obligatory. 

In line 7 tiie element "panel" is defined and tiie element type declaration specifies that tiie 
element "panel" may conqprise one or more elements out of the group of elemraits "gridlayout", 
"panel", "label", "textbox", "button", "Ustbox", "table" and "tree". The element type "panel" has 
further assigned an attribute type declaration, which includes an attribute "name" (cf. line 9), 
which is specified to contain character-encoded data content and to be obligatory. 

In linra 11, 17 and 25 are denoted a selection of element type declarations. The depicted screen 
document type description is not complete but the depicted screen document type description is 
an exceipt thereof such fliat only an example selection of example element type declarations are 
denoted. 
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For example reference should be given to the element type declaration of the element 'Tjutton" 
denoted in the lines 25 to 32. The element "button" is amplified with an attribute type declaration 

- comprising attributes "dataobject", "attribute", "name", "listener" and "layoutmanager". The 
attributes "dataobject", "attribute" and "name" are defined as obligatory and are specified to 

5 contain character-encoded data content. The attributes "listener" and "layoutmanager" are 
specifies as compulsory, wherein the attribute "Ustcsner" is specified to have a value out of the 
groiqj "ChangeListener" and 'TocusUstener" and the attribute "layoutmanager" is specified to 
contain charact^-encoded data content. 

10 The additional attributes of this attribute type declaration relate to the screen fimctionaUty. This 
is, the attribute "dataobject" allows for associating the element "button" and a widget "button", 
which is based on the element definition, with a certain determined data object, respectively. The 
attribute "name" allows for assigning an identification of tiie widget "button". The attribute 
"listener" relates to the handUng of user initiated events, i.e. user input which is to be mterpreted 

15 as mstniction, onto which a certain code section is to be processed. An event may include a cUck 
by a mouse on a "button" widget, an entering of text into a text accepting widget such as 
"texfeox" widget and the like. The denotation listener is JAVA progtammmg language specific 
but other programming languages supporting graphical user interfece generation also provides 
similar event handlers. Without going mto details of JAVA specifications, in case such an event 

20 is detected, a corresponding notification is generated and received by the event handler specified 
by tiie attribute "Ustener". The unplementation of events is essentially a typical callback system. 

hi contrast to currently discussed attribute type declaration it shall be noted that the attribute type 
declaration of tiie element "button" m tiie widget document type description (DTD) relates to tiie 
25 iqppearance of a widget "button" requested firam the defined pattem. 

The description given above appHes also in an analogous way to tiie elements "texflDOx" and 
"label" denoted m hues 17 to 24 and 1 1 to 16, which are not discussed in detail 

30 Fig. 4b shows a clear text codmg of an example screen configuration on tiie basis of the screen 
document type description shown m Fig. 4a according to an embodiment of tiie mvention. hi 
accordance witii tiw screen document type description (DTD) (cf. Fig. 4a and description) tiie 
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example screen configuration defines a deteimined example screen, which is embodied in Fig, 4c 
to support the aforementioned description. Therefore, the foUowing description with reference to 
Fig. 4b is completed with refoences to Fig. 4c. 

The example screen definition shows in exemplary way the hierarchical structure determined by 
the document type descriptions. An element "screen" defined in Ime 3 and designated with the 
name "Sample Screen" includes subordinated an element "panel" which again includes 
subordinated fiuther elements and widgets, respectively. The element "panel" corresponds to the 
widget 10 in Fig. 4c, which represents an area, onto which flie fiuther widgets are arranged. In 
line 5 the arrangement of the widgets on the panel is defined. Two elements "label" are defined in 
lines 6 and 9, which corresponding widgets 1 1 and 14 of the widget type "label" are depicted in 
Fig. 4c. Further, the definition of the element "textbox" in line 7 leads to the widget 12 (c£ Fig. 
4c), the definition of the element "button" m line 8 leads to the widget 13 (cf. Fig. 4c) and the 
elranoit "listbox" in line 9 leads to flie widget 14 (cf. Fig. 4c). 

In accordance with the widget configuration (cf. Fig. 3b), on which the depicted widgets are 
based, the "label" widgets and the labels contained thereby are embodied as "TimesRoman" font, 
respectively. Correspondingly, the "textbox" and "listbox" widgets and the content contained 
thereby are embodied as "Arial" font. This aspect relates to the defeult configuration of the 
widgets. 

The definition in line 8 specifies an element "button" which corresponds to the widget 13 (cf 
Fig. 4c). The definitions in lines 11 to 15 specify a second element "panel" included subordinated 
in the previous element "panel" and the second element "panel" comprises hierarchically 
subordinated two eleanents "button". The corresponding widgets are indicated as widget 16 (cf 
Fig. 4c) referring to the second element "panel", widget 17 (cf Fig. 4c) corresponding to the 
element "button" in line 13 and widget 18 (cf Fig. 4c) referring to the element "button" in line 
14. The hierarchical structuring of the screen definition is not limited to any number of 
hierarchical levels, i.e. for example each element of the type "panel" may comprise any number 
of fiirther hierarchical subordinately arranged fiirther elements of the type "panel". This results 
immediately firom the grammatical definition provided by the screen document type definition. 
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The elements, which coiresponds to widgets accepting user events, i.e. which accept data input 
C'textbox" widget 12) or which allows for user operation such as "listbox" widget 15 (cf. Fig. 
4c), "button" widgets 13, 17 and 18 (cf. Fig. 4c) include specifications of the data object and a 
conesponding listener, which is effected by the user event and which mediates and processes the 
5 user event, respectively. 

Conclusively, it shall be understood that the screen document type definition (DTD) specifies the 
elements (entities), on the basis of which concrete screen implementation and designs are carried 
out, respectively. The totally supported and available grammatical elCTients (entities) of soreen 
10 configurations are defined, which are coded as XML files. In analogy to the widget document 
type definition (DTD) the screen document type definition (DTD) is maintained by the core 
developers, since changes or modifications concern the parsing fimction, which is embodied as 
the soreen fkctory rel^red to in Fig 2. 

15 The screen configurations speci^g distinct screens of the graphical user mterfece (GUI), which 
is operable wifli the cUent application for displaying and modii^raig data of data objects, defines 
widgets, their hierardiy and the mapping of the widgets to the data objects. Further, the screen 
configuration defines the mapping of events occurring in coigunction witii user inputs to the 
widgets of the screen to event targets and listeners to handle the events correspondingly. 
20 Moreover, the screen configuration associates the logical widget definitions vdth implementation 
classes, of flie JAVA programming language. The implementation classes of the JAVA 
programming language are to be understood as exemplary. Various corresponding 
implementation classes may be used. The implementation of the screen configuration further 
enables to provide further specific logic, for example for implementing a checking of user input 
25 The search button 13 shown in Fig. 4c is operable with a mouse cUck to initiate a corresponding 
event. In a first operation in consequence on the initiated event an inserted logic may allow for 
checking whether an mput in the textbox widget 12 exists and is vaUd such that further operation 
may be denied in case the input in tiie textbox 12 is not valid or nor present. The screen 
configurations are in tiie responsibility of tiie GUI developCTS. 

30 

The above presented and described concept of defining screens of graphical user interfece is also 
employable to define parts of a screen independentiy from any distinct screen definition. Such 
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parts of a screen, which nmy be also designated as subscreen define an arrangement of one or 

more widgets. A corresponding similar definition has been explained with respect to the second 
" element panel in Fig. 4b with reference to lines 11 to 15, which comprises hierarchically 

subordinated two elements "button". In contrast to the including directly of the second element 
5 "panel" into the screen definition a separate independent subscreen definition may comprise this 

definition which can be included subsequently into the screen defmition illustrated with respect 

to Fig. 4b. 

Moreover, Ae advantage of a subscreen definition, performed analogously to flie presented 
10 screen definition, is, that the subscreen definition guarantees an identical appearance of fbs 
widgets included in the subscreen definition in each presented screen of the gr^hical user 
inter&ce (GUI) to the usa:. Further once defined subscreen definitions employable to be included 
into sevCTal screen definitions reduce significantly the eflfort of designing the ^earance of the 
graphical user interface and forces a common look and feel analogously to the comm<Hi look 
15 and feel resultmg fiwm the global widget definitionu The employment of subscreen definitions is 
not limited due to the unlimited hierarchical structuring usable in the screen definitions. The 
employment of subscreen definitions is preferably used for complicated or sophisticated widget 
arrangements, which are advantageously defined once to be mcluded in several screen 
definitions. 

20 

The association of widgets and data objects and as a result the interacting on events originating 
fi^om actions on data objects and widgets, respectively, will be more qjparent widi refer^ce to 
the Fig. 5a and Fig. 5b. 

25 Fig. 5a illustrates a schematic diagram, which illustrates the binding of data objects and widgete 

- according lo^ anbodiment of the invention. A screen widget container 400 shall logically 

comprise a set of widgets, which are exemplary depicted by widget 410. A data object container 
450 shall logically comprises a set of data objects, which are exemplary depicted by data object 
(DObj) 460. A linking component 430 mediates between the widgets of the screen widget 
30 container 400 and the data object container 450. 
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In addition to the operational sequence according to an embodiment of the present invention and 
described with reference to Fig. lb the widgets included in the dynamically created screen are 
linked with a data object (e.g. data object 460), which is placed in the data object container 450 
such that a binding between graphical user interface (GUI), which implements the viewer layer 
appUcation part, and the controller layer ^pUcation part is established to enable a displaying of 
the data object. The data object shall be understood as a logical collection , of fields, which 
include data content The data content may be mapped to individual widgets or may be supported 
and expressed in widgets such as tableboxes, listboxes and the like such that the data .content is 
displayable to the user and/or modifiable by the user. 
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The linking component 430 responsible for the linking / binding of data objects and widgets is 
further involved in a notifying for changes relating to the data objects. That means, in case a 
change affecting a data object (such as data object 460) occurs the data object container 450 or 
the data object a^ted by the change notifies in an operation S400 the linking component 
15 (bmding component) 430 about the change and the linking component 430 mediates in an 
operation S410 this notification to the corresponding one or more widgets which are affected by 
&e change. The mediating may comprise a finding operation, which allows the linking 
component 430 for identifying the affected widgets such as widget 410. 

20 In more detail, the notification about a change, which has been effected in a data object, is 
recursively mediated. With reference back to Fig. 3b, the widget pattern definitions are based on 
a widget library, which is provided to be used for example by an operating system of a cbmputer 
or in particular by a distinct programming language such as the example JAVA programming 
environment Corresponding definitions have been explained with respect to the attribute "class". 
25 which coiiq>rises an indication to the concrete widget (e.g. cf. line 4 of Fig. 3b). Further, that 
means, the linking component 430 mediates in the operation S410 the change notification to one 
or more widget components of the XML-based graphical user interfiice fiameworic, and in 
particular to one or more instances of the widget components created in consequence on creating 
a screen. These widget component instances recursively mediate the change notification to the 
30 widget and the widget instances of the widget Ubrary, respectively, which is employed for 
performing the widget appearance. 
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Fig. 5b iUustrates a schematic diagram that depicts the logical linkage of components interacting 
with each other on handling a data object change notification according to an embodiment of the 
invention. 

5 The schematic diagram illustrates schematic entities, which relates to components, code sections 
and elements involved in the data object displaying and handling, respectively. A certain 
detemiined screen, which comprises a widget, may be presented by the graphical user interfiice to 
a user. Jn Fig. 5b, this screen is depicted as screen instance 500, whereas flie widget is dq>icted as 
widget 410. It may be further assumed that the widget 410 is a "listbox" widget, which allows for 
10 displaying a set of fields arranged m a Ust, Moreover, the ^istbox" widget 410 may be employed 
to display a list of contracts that are associated with a certain deal. The data object (DObj) 460 
may represent the deal, whereas the list of contracts may be represented by the data object 
(DObj) 465. 

15 Assuming furthermore, that the user of the graphical user interfece wants to change the displayed 
deal and has mitiated a corresponding event. With view to Fig. 4c, the user may have inputted a 
new account number into the "textbox" widget 12, which identifies the aforementioned deal, and 
may have selected the search "button" widget 13, which has initiated a corresponding event 
passed on to the listener defined in the s^een configuration (cf. line 8). 

20 

The "listbox" widget 410, which displays the contracts associated wiA the inputted account 
number of the deal has to be updated. The event initiated by the selection of the search "button" 
widget 13 is passed to the screen and screen mstance 500. respectively, which is defined as 
"target" of events (cf line 8 in Fig. 4b). The screen instance 500 delegates the event to its screen 

25 base class 510. such as defined in Ime 3 depicted in Fig. 4b- On receiving the select event, the 
• screen base class 510 requests the data object loading component 600 for a new data object in 
accordance with the user input inputted in the "textbox" widget 12 and the data object loading 
component 600 places the coniesponding new data object in the data object container 450. Now, 
the operational sequence follows the operational sequence illustrated in Fig. 5a. The data object 

30 container 450 indicates to the screen base class 510 that a new data object is present On 
receiving of the notification that a change has occurred on the data object in the data object 
container450, the screen base class 510 may invalidate the graphical user interfece (GUI) and 



force arefreshing (r^ainting, updating) of the "listbox" widget 410 such that the data (i.e. the Ust 
of contracts) of the new data object is displayed by the graphical user interfece (GUI) to the user. 

The schematic diagram depicted m Fig. 5b illustrates additionally relationships between the 
5 components discussed above. The illustrated relationship is based on a unified modeling 
language (UML) draiotation, which is employed for depicting and denoting complex dependency 
structures. The screen instance 500 is a member of the screen base class 510 acting as 
superordinate screen class. The data objects 460 and 465 are indicated as data objects being part 
of an aggregation of data objects which aU belong to the superordmate data object container 450. 
10 The data object container 450 is again a member of the superordinated screen base class 510. A 
data object Ustener 610 and 620 is associated with the corresponding data objects 640 and 465, 
respeptively. Moreover, the data object listeners 610 and 620 are linked (associated) to the screen 
base class 510 and each data object listeners is linked to a conresponding widget for receiving 
events. Herein, the data object listener 620, which is associated with the data object 465 
15 representing ttie Ust of contracts, is linked with the widget 410, which shall represents the 
"listbox" wid^ for displaying the list of contracts such as "listbox" widget 15. Furthermore, the 
class instance 500 is also linked to each widget included in the class instance 500, which is 
exemplary illustrated in conjunction with widget 410. Finally, the data object loading component 
600 is associated with the screen instance for operating. 

20 

It shall be noted that the description of the widget pattern generation has been illustrated m view 
of an initial process which results in a static providing of widget patterns by a widget pattern 
repository, on the basis of which widgets to be included into a screen for being displayed by the 
graphical user interface (GUI) are derived (requested and cloned, respectively). Alternatively, the 

25 widget patterns, which are required for deriving the widgets to be included in tiie screen, may be 
also created dynamically. That is, the request for a certain predetermined widget issued by the 
screen jBwtory 240 mstructs the widget fectory 230 to dynamically create a corresponding widget 
pattern, on tiie basis of which tiie requested widget is generated preferably by the widget fectory 
230 but also instead of this by the screen fectory 240. The corresponding widget pattern is 

30 created on demand, which eluninates the necessity of a widget pattern repository 210. The 
creating on demand further may require a identifying operation, which is preferably operated by 
the widget fectory 230 and which allows for identifying tiiis part of the complete widget 
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configuration 310, which relates to the widget pattern definition, which conesponds to the 
requested widget. The widget pattern repository and widget cache 2^0 speeds up the screen 
creating process, respectively, such that implementation is advantageous. 

It shall be noted that the conoponents included in the presented terminal device perfonning 
functions and operations according to an embodiment of the invention may be constituted by a 
data processing device which may be comprised by the terminal device. Further, the components 
may be constituted by code sections for executing on one or a plurality of data processing devices 
containing instructions for canying out the necessary processing operations for performing 
functions and operations. The functions or operations are exemplary presented widi respect to the 
aforementioned methods according to embodiments of the invention. The operational sequences 
shall represent operations, which may be carried out by one or more dedicated conqtoiients, 
vfidch are preferably code sections containing instructions to allow for operation 
correspondingly. Alternative composition of components and a association of operations to 
different conqjonents is possible wifliout departing the scope of the invention. It will be obvious 
for fliose skilled in the art that as the technology advances, the inventive concept can be 
implemented m a broad numbra- of ways. The invention and its embodiments are thus not limited 
to the examples described above but may vary within the scope of the claims. 
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Claims 

Method for providing a user interface (GUI) which is operable by a user to operate an 
appUcation, wherein the ^pUcation is structured into a core application part responsible to 
handle data objects and a viewer/controller application part responsible to diq)lay said data 
and to initiate actions on said data, wherein said viewer/controllOT application part is formed 
by said user inter&ce (GUI); characterized by 

_ providing central configuration information comprising a componoxt configuration and at 
least one screen mask configuration; 

wherein said component configuration comprises component configuration data about aU 
components, which are available to be included in screen masks of said user interface; 
wherein said screen mask configuration comprises screen mask configuration data about a 
predetermined screen mask of said user mterfece, wherein said screen mask comprises at 
least one component which is a component out of said components comprised by the 
component configuration; 

- creating said predetermined screen mask of said user interfece on the basis of said central 
configuration information; and 

- linking said at least one component of said created screen mask to at least one data object 

2. Mefliod according to claim 1, comprising: 

- jetrieviQg (S210) said screen mask configuration (320); 

- parsing (S220) said screen mask configuration (320) to obtain type information about said 
at least one component (10 - 18; 410) and to obtain individual settings of said at least one 
component (10 - 18; 410); 

- creating (S230) said at least one component (10 - 18; 410) by 

- obtaining (S231) said at least one component (10 - 18; 410) on the basis of at least 
one component pattern (41 1, 412) conresponding to said type information; and 

_ applying (S232) said individual settings onto said at least one component (10 - 18; 
410); and 

- including said at least one component (10 - 18; 410) into said screen mask. 
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3. Method according to claim 2, wherein said obtaining of said at least one component (10 - 18; 
410) comprises: 

- requesting said at least one component (10 - 18; 410) from a component pattem 
repository (210), ivfaich caches at least one componCTt pattem (41 1, 412); 

- identi^ng said at least one component pattem (411, 412) corresponding to said type 
information; and 

- deriving said at least one component (10 - IS; 410) from said at least one identified 
component pattem (411, 412). 

4. Method according to claim 3, wherein said component pattem repository (210) is initialized 
by: 

- retrieving (SllO) said conqjonent configuration (310), which comprises component 
configuration data about at least one component patt^ (41 1, 412); 

- parsing (S120) said componmt configuration (310); 

- creating (S130) said at least one component pattem; and 

- storing said at least one component pattem in said component paitsm repository (210). 

5. Method according to claim 3 or claim 4, wherein said component pattem repository (210) 
contains statically said at least one conqjonent pattem (41 1, 412) during runtime of said 
application. 

6. Method accordmg to claim 2, wherein said obtaining of said at least one component (10-18; 
410) comprises: 

- requesting said at least one component (10 - 18; 410); 

- retrieving (SllO) a component configuration (310), which comprises component 
configuration data about at least one component pattem (41 1, 412); 

- identifying said component configuration data about said at least one component pattem 
(41 1, 412) corresponding to said extracted type information; 

- parsing (S 1 20) said identified component configuration information; 

- creating (S 1 30) said at least one component pattem; 

- deriving said at least one component (10 - 18; 410) from said at least one component 
pattem (411, 412). 
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7. Method according to anyone of the preceding cldms, wherein said obtaining of said at least 
one component (10 - 18; 410) comprises: 

. cloning said at least one component pattern (411, 412) to obtain said at least one 
component (10 - 18; 410). 

8. Method according to anyone of the preceding claims, wherein said component configuration 
(310) comprises default component configuration information about said at least one 
component pattern (411, 412) such that components (10 - 18; 410) obtained from said least 
one component pattern (41 1, 412) have default settings vaUd for substantially all components 
used in the user interface (GUI). 

9. Method according to anyone of the preceding claims, wherein screen mask configuration 
(320) comprises screen mask configuration data about at least one component (10 - 18; 410) 
to adapt said component (10 - 18; 410), which is obtained from said corresponding 
component pattern (411, 412), to requirements presupposed by said screen mask to be 
created. 

10. Method according to anyone of the preceding claims, wherein said screen mask configuration 
(320) is an XML-encoded screen mask configuration, which is based on a screen mask 
document type description (DTD; 340). 

11. Method according to anyone of the preceding claims, wherein said widget configuration 
(310) is an XML-encoded widget configuration, which is based on a widget document type 
description (DTD; 330). 

12. Software tool for estabUshing a user interface (GUI), comprising program portions for 
carrying out the operations of any one of the claims 1 to 11, when said program is 
implemented in a computer program for being executed on a microprocessor-based device, 
processing device, a terminal device or a network device. 
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t. Computer program product for establishing a user interfece (GUI), comprising loadable 
program code sections for canying out the opoations of aiqr one of the claims 1 to U, when 
said program code is executed on a microprocessor-based device, processing device, a 
temiinal device or a network device. 

. Computer program product for establishing a user interface (GUI), wherein said computer 
program product is comprising program code sections stored on a computer readable medium 
for carrying out the method of any one of the claims 1 to 11, when said computer program 
product is executed on a microprocessor-based device, processing device, a terminal device 
or a network device. 



15. Computer data signal embodied in a carrier wave and r^resenting instructions which whai 
executed by a processor cause flie steps of anyone of claims 1 to 1 1 to be carried out. 

16. Taminal device ad^ted to estabUsh a user interfece (GUI), which is operable by a user to 
operate an application executed by said terminal desvice. which comprises: 

- a screen mask creatuig component (240) for creating dynamically a screen mask of said 
user inter&ce (GUI), comprising: 

- a retrieval component (260, 270) for retrieving a screen mask configuration (320), 
which comprises screen mask configuration data about at least one component (10 - 
18; 410); 

- a parsing component (250, 240) for parsing said screen mask configuration (320) to 
obtain type information about said at least one component (10 - 18; 410) and to obtain 
individual settings of said at least one component (10 - 18; 410); 

- a widget creating component (240) for obtaining said at least one component (10 - 1 8; 
410) on the basis of at least one component pattern (41 1, 412) corresponding to said 
type information and for applying said individual settings onto said at least one 
component (1 0 - 1 8; 41 0); and 

- a linking component (430) for linking said at least one component (10 - 18; 410) to at 
least one data object (460, 465). 

17. Terminal device according to claim 16, comprising: 
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- a component pattern repository (210) which caches at least one component pattern (41 1, 
412) and &om which at least one component (10 - 18; 410) is requested; and 

. an identification component (240) for identifying at least one component pattern (411, 
412) corresponding to said extracted type information; 

wherein said .widget seating component (240) is adapted to derive at least one component 

(10 - 18;-410) fifom said at least one identified component patt^ (41 1, 412). 

18. Terminal device according to claim 16, wherein said terminal device comprises furtber 
components for initialization of said componrait pattern repository (210): 

- a retrieval component (260, 270) for retrieving a component configuration (310), which 
comprises component configuration data about at least one component pattern (41 1, 412); 
and 

- a parsing component (250, 230) for parsing said component configuration information; 
wherein said widget creating component (230) is adapted to create said at least one 
component pattern (41 1, 412) and to store said at least one created conq)onent pattern (41 1, 
412) in said componCTt pattern repository (210). 

19. Temiinal device according to claim 16, comprising: 

- a retrieval component (260, 270) for retrieving a component configuration (310), which 
comprises componoit configuration information about at least one component pattern 
(411,412); 

- an identification component (240) for identifying said component configuration 
information about said at least one component pattern (411, 412) corresponding to said 
extracted type information; and 

- a parsing component (250, 230) for parsing said identified con^onent configuration 

infiirmation; 

wherein said widget creating component (230) is adapted to create said at least one 
component pattern (411, 412) and to derive said at least one component (10 - 18. 510) from 
said at least one conq>onent pattom (411, 412). 
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The presesnt invention relates to a method for generation of a user interface. In particular, the 
present invention relates to a method for generation of graphical user interface (GUI) on the basis 
of a central configuration arrangement. More particular, the method takes considerations of 
JAVA programming enviionmrait and employs a central configuration arrangement, which is 
coded in a vmiversal markup language such as the extensible markup language. 

The user interface (GUI) is operable by a user to operate an application. The plication is 
structured into separate layers; i.e. a core application layer which is responsible to handle data 
objects and data of the data objects and a viewer/controller ^pUcation layer, whicb is 
responsible to display data contamed in one or more data objects and to initiate actions (events) 
on the data and the data objects, respectively. The viewer/controller application layer is formed 
by tiie user inter&ce (GUI). 

Central configuration information is provided, which comprises a component configuration 
information and at least one screen mask configuration information. The mfomMtion about the 
component configuration comprises m particular component configuration information about all 
components, which are available to be included in screen masks of the user interface. The 
components are operable as one component out of a group components, which conqjrises a 
component for outputting data, a component for inputting data and component for both 
outputting and inputting data. The information about the screen mask configuration comprises in 
particular screen mask configuration mformation about a predetermined screen mask of the user 
interfece. The screen mask comprises at least one conqjonent which is a component out of the 
ffxnxp of components comprised by the component configuration. The predetermined screen 
mask of the user inter&ce is created on the basis of the central configuration information and the 
at least one component of the screen mask is linked to at least one data object The linking 
enables that an action, which is initiated via the at least one component is effects correspondingly 
the data object and that a modification, which has effected the data object is noticed by the at 
least one component such that the component can react correspondingly. The appearance of the 
user interface is defined by the central configuration information. Modifications on the 
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appearance of the user interfece is obtainable by modifications on the central configmation 
information. 



(Fig. Ic) 
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1: <?xm\ version="1,0'' encodlng="ISO-8859-1"?> 

2: <!ELEMENT vwdgetdefinltion (panel | button | listbox | textbox | label | grfdiayout | ftowlayout | tabpane)*> 

3: <iATTLISTwiclgetdefinftion 

4: laf (Metal | Motif | Wmdcnws | Mac) #REQUIRED 

5: > 

6: <l ELEMENT panel (flowlayout | bevelborder)> 

7: <!ATTLIST panel 

8: class COATA ^REQUIRED 

9: font CDATA #IMPLIED 

10: > 

11: <IELEMENT label ((bevelborder)?, font?r> 

12: <!ATTLIST label 

13: class CDATA #REQUIRED 

14: font CDATA #IMPUED 

15: > 

16: <IELEMENT button ((bevelborder)?, font?)?> 

17: <IATTLIST button 

18: class CDATA #REQUIRED 

19: name CDATA #IMPLIED 

20: > 

21: <!ELEMENT textbox ((bevelborder)?, fbnt?r> 

22: <!ATTLIST textbox 

23: class CDATA #REQUIRED 

24: name C^DATA #IMPLIEO 

25: > 

2a- <IELEMENT gridlayout EMPTy> 

27: <IATTUST gridlayout 

28: class CDATA #REQUIRED 

29: > 

30: <! ELEMENT bevelborder EMPTV> 

31 : <I ATTLIST bevelborder 

32: class CDATA ^ff^lXED "javax.swlng.border.BevelBordei- 

33: border (LOWERED | RAISED) #REQUIRED 

34: > 

35: <! ELEMENT flowlayout EMPTY> 

36: . <IATTLIST flowlayout 

37: class CDATA REQUIRED 

38: > 

39: <lELEMENTfontEMPTY> 

40: <IATTLISTfont 

41: name CDATA #REQUIRED 

42: size CDATA #REQUIRED 

43: style (PLAIN | BOLD | ITALIC) #REQUIRED 

44: class CDATA #FIXED "java.awLFonr 

45: > 

46: <IELEMEIMTtabpane(#PCDATA)> 

47: <! ATTLIST tabpane 

48: class CDATA #REQUIRED 

49: > 



... continues ... 



Fig. 3a 
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1: 


<7xml verslon=^1.0" encoding=^ISO-8859-1"?> 


2: 


<IDOCTYPE wldgetdefinition SYSTEM "WidgetDefinition.dtd'^ 


3: 


<w!dgetdefinition laf="Metar> 


4: 


<button class^iavax.8wlng.JButton"> 


5: 


<font name=nnmesRoman" slze="10" style="PLAIN**/> 


6: 


</button> 


7: 


<panel class^avax.swing.JPaner> 


8: 


<bevelborder border=TOWERED7> 






10: 


<afs1l3ox class»^vax.swing. JLIst"> 


11: 


<font name="Ariar size="18- style="PLAlN7> 


12: 


<bevelboider bordep="LOWERED"> 


13: 


</listbox> 


14: 


<texlbox class="javax.swing. JTextFie!d"> 


15: 


<font name="Ariar slze="10- style^PLAIN"> 


16: 


<bevelborder border=^LOWERED"/> 


17: 


</textbox> 


18: 


<gridlayout classs*'java.awt.Gr!dLayour/> 


19: 


<flowlayout class="java.awt.FlowLayout"/> 


20: 


<iabe1 class»''Javax.swing .JLabel**> 


21: 


<fbnt name=^'Arlar slze=^10" style!=*BOLD"A* 


22: 


<bev^border bordep=^LOWERED"> 


23: 


</label> 


24: 


<tabpane cIass=lavax.swlng.JTabb8dPane7> 


25: 


<AAridgetdefln]tion> 




Fig. 3b 
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1: <7wnl vefslon=^1.0" encoding="ISO-8859-1*^ 

2: . <!ELEMENT screen (pariel)> 

3: <IATrLIST screen 

4: name CDATA #IMPL1ED 

5: dass CDATA #REQUIRED 

6: > 

7: <!ELEMENT panel ((gridlayout). (panel | label | textbox | button | listbox | table | tree)+)+> 

8: <!ATTLIST panel 

9: name CDATA #REQUIREO 

10: > 

11: <!ELEMENT label EIWPTY> 

1^ <!ATTLIST label 

13: name CDATA #REQUIRED 

14: listener CDATA IMPLIED 

1 5: layoutmanager CDATA ^IMPLIED 

16: > 

17: <IELEMENT textbox (#PCDAtA)> 

18: <IATTLIST textbox 

19: dataobjectCDATA ^REQUIRED 

20: attribute CDATA #REQUIRED 

21: name CDATA #REQUIRED 

22: fistener NOTATION (ChangeUstener | FocusLlstener) #IMPLIED 

23: Is^outmanager CDATA #IMPLIED 

24: > 

25: <1ELEMENT button EMPTY> • 

26: <!ATTLIST button 

27: dataobjectCDATA #IMPLIED 

28: name CDATA #REQUIRED 

29: listener NOTATION (ChangeUstener | FocusLlstener) ^REQUIRED 

30: target NOTATION (screen I dataobject) #REQUIR£D 

31: layoutmanager CDATA #1MPLIED 

32: > 

... continues ... 



Fig. 4a 
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1 : <?xm! version="1 .0" encoding="ISO-8859-1"?> 

2: <lDOCTYPE screen SYSTEM "scrBen.dtcr> 

3: <scrBen name="Sampte Screen" cIass=:^xgx.screen-AccountVlew"> 



4: <panel name=" Accounts'^ 

5: . <gridIayout row="3" col="3'/> 

6: <label name="Accounr/> 

7: <textbox name=^tb_accounr attribute="account_no" dataobject="Accounls" listener="ChangeListener/> 

8: <button name="Search" dataobject ^"Accounts" listenep=^ChangeUstener" target="scr8en''/> 

9: <label name=^ContFacr/> 

10: <!lstbox name=-account.no" dataobject =^Accounts" attribute="account_no- llstener="FocusUstener/> 

1 1 : <panel name="test*^ 

12: <gridlayout row=^1" ooN"2"/> 

1 3: <button dataobject="Accounts" name="Ok- target="screen" llstenep=^ChangeListener/> 

i4: <button dataobject="Accounts" name="Cancer target="dataobiecr listenep^ocusUstenef"A> 

15: </panel> 

16: </panel> 



17: </screen> 

Fig. 4b 




Fig. 4c 
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